perm filename ILISP.MAN[RUT,LSP]1 blob
sn#267599 filedate 1977-03-05 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00034 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00006 00002
C00011 00003 RUTGERS/UCI LISP MANUAL Page 2
C00016 00004 RUTGERS/UCI LISP MANUAL Page 3
C00020 00005 RUTGERS/UCI LISP MANUAL Page 4
C00024 00006 RUTGERS/UCI LISP MANUAL Page 5
C00028 00007 RUTGERS/UCI LISP MANUAL Page 6
C00032 00008 RUTGERS/UCI LISP MANUAL Page 7
C00035 00009 RUTGERS/UCI LISP MANUAL Page 10
C00039 00010 RUTGERS/UCI LISP MANUAL Page 11
C00043 00011 RUTGERS/UCI LISP MANUAL Page 10
C00047 00012 RUTGERS/UCI LISP MANUAL Page 11
C00050 00013 RUTGERS/UCI LISP MANUAL Page 12
C00053 00014 RUTGERS/UCI LISP MANUAL Page 13
C00055 00015 RUTGERS/UCI LISP MANUAL Page 14
C00060 00016 RUTGERS/UCI LISP MANUAL Page 15
C00064 00017 RUTGERS/UCI LISP MANUAL Page 16
C00067 00018 RUTGERS/UCI LISP MANUAL Page 17
C00070 00019 RUTGERS/UCI LISP MANUAL Page 110
C00071 00020 RUTGERS/UCI LISP MANUAL Page 111
C00074 00021 RUTGERS/UCI LISP MANUAL Page 20
C00079 00022 RUTGERS/UCI LISP MANUAL Page 21
C00084 00023 RUTGERS/UCI LISP MANUAL Page 22
C00088 00024 RUTGERS/UCI LISP MANUAL Page 23
C00092 00025 RUTGERS/UCI LISP MANUAL Page 24
C00096 00026 RUTGERS/UCI LISP MANUAL Page 25
C00101 00027 RUTGERS/UCI LISP MANUAL Page 26
C00106 00028 RUTGERS/UCI LISP MANUAL Page 27
C00111 00029 RUTGERS/UCI LISP MANUAL Page 210
C00115 00030 RUTGERS/UCI LISP MANUAL Page 211
C00120 00031 RUTGERS/UCI LISP MANUAL Page 30
C00122 00032 RUTGERS/UCI LISP MANUAL Page 31
C00127 00033 EXPBPS . . . . . . . . . . . . . . . . . . . . . 6
C00132 00034 Q (The Octal Point) . . . . . . . . . . . . . . 14
C00137 ENDMK
C⊗;
RUTGERS/UCI LISP MANUAL
Rick LeFaivre
Computer Science Department
Rutgers University
February 22, 11177
RUTGERS/UCI LISP MANUAL Page 2
CONTENTS
←←←←←←←←
I. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . 3
Documentation Conventions . . . . . . . . . . . . . . 3
II. USER INTERACTION . . . . . . . . . . . . . . . . . . . 4
Terminal Interrupts . . . . . . . . . . . . . . . . . 4
Terminal Input . . . . . . . . . . . . . . . . . . . 5
Defining New Functions . . . . . . . . . . . . . . . 5
Expansion of Core . . . . . . . . . . . . . . . . . . 6
Exiting from LISP . . . . . . . . . . . . . . . . . . 6
System-Monitoring Functions . . . . . . . . . . . . . 7
III. NEW LANGUAGE FACILITIES . . . . . . . . . . . . . . . . 10
The New NIL . . . . . . . . . . . . . . . . . . . . . 10
ATOM, CONSP, and PATOM . . . . . . . . . . . . . . . 10
Funargs and SPDL Pointers . . . . . . . . . . . . . . 10
Functions for Controlling Evaluation . . . . . . . . 10
Functions for Manipulating Property Lists . . . . . . 10
New Mapping Functions . . . . . . . . . . . . . . . . 11
New List-Manipulation Functions . . . . . . . . . . . 12
New Functions on Strings . . . . . . . . . . . . . . 13
IV. NEW I/O FACILITIES . . . . . . . . . . . . . . . . . . 14
The Octal Point "Q" . . . . . . . . . . . . . . . . . 14
36-Bit Integers . . . . . . . . . . . . . . . . . . . 14
Changes to DSKIN/DSKOUT . . . . . . . . . . . . . . . 14
New File-Accessing Functions . . . . . . . . . . . . 15
New Printing Functions . . . . . . . . . . . . . . . 16
Miscellaneous I/O Functions . . . . . . . . . . . . . 17
V. NEW DEBUGGING FACILITIES . . . . . . . . . . . . . . . 111
Additions to the Editor . . . . . . . . . . . . . . . 111
Additions to the Break Package . . . . . . . . . . . 111
VI. THE LISP PRETTYPRINTER . . . . . . . . . . . . . . . . 20
Basic Functions . . . . . . . . . . . . . . . . . . . 20
PRETTYPROPS . . . . . . . . . . . . . . . . . . . . . 20
Prettyprint Commands . . . . . . . . . . . . . . . . 21
Printmacros . . . . . . . . . . . . . . . . . . . . . 22
Comments . . . . . . . . . . . . . . . . . . . . . . 24
VII. THE COMPILER AND LAP . . . . . . . . . . . . . . . . . 25
Declarations . . . . . . . . . . . . . . . . . . . . 25
Extensions to NOCALL . . . . . . . . . . . . . . . . 26
In-Line Code . . . . . . . . . . . . . . . . . . . . 27
Other Extensions . . . . . . . . . . . . . . . . . . 210
VIII. INFORMATION FOR THE SYSTEM BUILDER . . . . . . . . . . 211
User Error Handling . . . . . . . . . . . . . . . . . 211
Creating One's Own System . . . . . . . . . . . . . . 211
Building ILISP . . . . . . . . . . . . . . . . . . . 30
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
RUTGERS/UCI LISP MANUAL Page 3
I. INTRODUCTION
←←←←←←←←←←←←←←←
This manual describes ILISP, an extended version of
UCI LISP, which is itself an extended version of Stanford
LISP 1.6. The existing documentation for ILISP is spread over
three documents, reflecting the various stages in the development
of the system:
(1) SAILSP.MAN Describes the basic LISP 1.6 upon which
UCI LISP is based.
(2) UCILSP.MAN Describes the modifications and
additions contained in the UCI LISP
system as available from UC-Irvine.
(3) ILISP.MAN (This document). Describes the
modifications and additions contained
in the ILISP system as available from
Rutgers.
We assume here that the reader is familiar with the UCI LISP
system as described in (1) and (2) above - this document
describes only the Rutgers modifications and additions. Note
that there are numerous minor modifications and corrections to
UCI LISP which have no direct user impact, and thus are not
described in this manual. The interested LISP maintainer is
referred to the various source listings for detailed information.
Document Conventions
←←←←←←←←←←←←←←←←←←←←
In this manual arguments to functions are represented as
meta-linguistic variables of the form <variable>. Each function
is presented as a template, with arguments which will be
evaluated indicated by preceding them with "@". For example,
(SETQ <atom> @<value>)
indicates that <atom> is not evaluated and <value> is. Arguments
which are optional are indicated by enclosing them in braces,
e.g., {<x>}, and an unlimited number of arguments is indicated by
ellipses (. . .).
RUTGERS/UCI LISP MANUAL Page 4
II. USER INTERACTION
←←←←←←←←←←←←←←←←←←←←
The ILISP system is started by typing
.R ILISP
at monitor level. The compiler is called ILISPC, and may be run
via
.R ILISPC
(see section VII for details on the compiler). The system also
comes with ILISP versions of the AI languages MICRO-PLANNER
(.R PLNR), CONNIVER (.R CNVR), and FUZZY (.R FUZZY).
Terminal Interrupts
←←←←←←←←←←←←←←←←←←←
One of the major advantages of ILISP over UCI LISP and
LISP 1.6 is the presence of a terminal interrupt-handling
facility. The interrupt routine is entered by striking a single
↑C (Control-C) if awaiting terminal input, or two consecutive
↑C's if computing. The interrupt routine types:
Interrupt (?):
and awaits an interrupt character from the user. Typing "?" will
produce the following list of choices:
CR = Continue (Ignore ↑C)
↑D = Return to Top Level
↑X = Exit to Monitor via (EXIT NIL)
↑H = Break Next Fn Call
↑B = Back Up and Break Last Fn Call
↑G = (ERR @ERRORX)
↑E = (ERR NIL)
↑R = Restore System OBLIST
Typing a carriage return causes ILISP to continue doing whatever
it was doing when the ↑C was typed. ↑H, ↑B, ↑G, ↑E, and ↑R are
as described in the UCI LISP manual under the ↑C REENTER
procedure (which is now obsolete). ↑D causes an immediate return
to the top level of LISP, and ↑X causes an exit to the monitor
(see EXIT). A subsequent CONTINUE at monitor level will cause
ILISP to continue where it left off, and START will cause it to
restart at the top level (like ↑D). REENTER is no longer used.
Any other character is ignored by the interrupt routine. The
system is fully protected against a ↑C interrupt occuring at the
wrong time; for example, if ↑C is typed during a garbage
collection the garbage collection is completed before the
interrupt is recognized.
RUTGERS/UCI LISP MANUAL Page 5
Terminal Input
←←←←←←←←←←←←←←
In addition to the above interrupt characters, which are
recognized after a ↑C interrupt, there are three special control
characters which are active during terminal input.
As before, ↑G causes an (ERR @ERRORX) to occur, returning
either to an (ERRSET <x> ERRORX) if present or to the top level.
Recall that this character may be changed via
(ERRCH @<char>)
where <char> is the ASCII value of the new character. ERRCH
returns the ASCII value of the old error character.
Two new control characters affect the handling of errors
during terminal input. If the error is in the current line, the
system line-editing features may of course be used (RUBOUT/DELETE
or ↑H to delete a character, ↑U to delete the line, ↑R to retype
the line). In standard UCI LISP, if an error was noticed after
carriage return was struck, the user was forced to abort the
entire procedure via ↑G. ILISP now provides a "reread character"
↑Z which causes READ to ignore what was typed previously and
start over. The reread character may be changed via
(REREADCH @<char>)
which is similar to ERRCH in its operation.
Occasionally an error is not discovered until a good deal of
typing has taken place. Rather than starting over, an "edit
character" ↑F (for "fix") is also provided which causes the LISP
editor to be called when the expression is completely entered (↑F
may be typed at any point within the expression). The user may
then correct the expression, returning the edited version as the
value of the READ when OK is typed. The edit character may be
changed via
(EDITCH @<char>)
which is similar to ERRCH and REREADCH.
Defining New Functions
←←←←←←←←←←←←←←←←←←←←←←
The name of each function defined via DE, DF, or DM, or
edited via EDITF, is now kept on the list ALLFNS. This list may
be consulted after a long terminal session to see what functions
have been created or modified and must therefore be saved before
exiting.
If an existing function is redefined via DE, DF, or DM, the
old definition is now saved on the property list of the function
name under the property UNSAVE. The old definition may be
restored via
RUTGERS/UCI LISP MANUAL Page 6
(UNSAVE <name>)
if desired. The saving of old definitions may be disabled by
setting UNSAVE to NIL (it is initially T).
Expansion of Core
←←←←←←←←←←←←←←←←←
If ILISP is started with its low segment expanded beyond its
normal limit, the initial allocation procedure is entered as
before. However, it is recommended that one of the following new
functions be used to expand core without leaving LISP:
(REALLOC @<fws> @<bps> @<rpdl> @<spdl> @<fs>)
REALLOC's arguments specify increments (in words) to be
added to each of the five major allocation areas:
fullword space, binary program space, the regular
pushdown list, the special pushdown list, and free
storage (i.e., list space). After expanding core as
necessary and reallocating storage, REALLOC returns
control directly to the top level of LISP. In order to
retain control, the user must set up an INITFN which will
be called after REALLOC returns.
(EXPFWS @<fws>)
For those of us who can't remember the order of the
arguments to REALLOC, EXPFWS is equivalent to:
(REALLOC @<fws> 0 0 0 0)
(EXPBPS @<bps>)
Equivalent to (REALLOC 0 @<bps> 0 0 0).
(EXPFS @<fs>)
Equivalent to (REALLOC 0 0 0 0 @<fs>).
Exiting from LISP
←←←←←←←←←←←←←←←←←
(EXIT @<flag>)
ILISP may be exited via the EXIT function. <flag>
specifies whether ILISP's sharable high segment should be
deleted (<flag>=NIL) or retained (<flag>=T) before
exiting. There is normally no reason to retain the high
segment, as it is automatically loaded when ILISP is
STARTed or CONTinued. By deleting the high segment, EXIT
allows the user to exit from LISP and save the low
segment as a runnable SAV file - when the file is later
RUN, ILISP's sharable high segment will be loaded
automatically. (Note that an EXCISE or SYSCLR should be
RUTGERS/UCI LISP MANUAL Page 7
performed before exiting if the low segment is to be
saved - see section VIII for more details). (EXIT T) is
necessary only after SETSYS has been used to create a new
sharable system, when both the low and high segments must
be saved. At the top level, (EXIT) (and ↑C ↑X) are
equivalent to (EXIT NIL).
System-Monitoring Functions
←←←←←←←←←←←←←←←←←←←←←←←←←←←
(FSCNT)
Returns the length of the free storage list, i.e., the
number of available cons cells.
(FWCNT)
Returns the length of the fullword list.
(DTIME)
Returns the time of day in milliseconds past midnight.
(DATE)
Returns the current date as a list of the form:
(<month> <day> <year-11100>)
(TIMER {<expr1>} {<expr2>} . . .)
TIMER serves as either an evaluation timer or an
incremental timer. If any arguments are present they are
evaluated, the execution time, number of conses, and
garbage collection time are printed, and the value of the
last expression is returned. For example,
(TIMER (GC) (GC)) times two garbage collections. If
TIMER is called with no arguments (i.e., (TIMER)), the
execution time, number of conses, and garbage collection
time since the last evaluation of (TIMER) are printed and
a value of NIL is returned. The intent here is that
TIMER will be called once to initialize it, a number of
expressions will be evaluated, and then TIMER will be
called again to check the incremental execution time,
etc.
RUTGERS/UCI LISP MANUAL Page 10
III. NEW LANGUAGE FACILITIES
←←←←←←←←←←←←←←←←←←←←←←←←←←←←
The New NIL
←←←←←←←←←←←
In keeping with its character as both an atom and the
representation of the empty list, the atom NIL has been modified
so that its CAR and CDR are both NIL. One can now, for example,
pick up the arguments to an FEXPR via a sequence of CAR/CDR
combinations, with missing arguments automatically set to NIL.
Note that NIL now has a usable property list, although it is not
stored as the CDR of NIL as with other atoms (GET, PUTPROP, etc.
are all aware of its actual location).
ATOM, CONSP, and PATOM
←←←←←←←←←←←←←←←←←←←←←←
ATOM has been fixed to return T only for a true LISP atom
(i.e., an atomic symbol or a number). It will no longer be true
if its argument is a pointer to some other location which happens
to have -1 in its CAR field. Similarly, CONSP is true only if
its argument is a true LISP consed cell. It is now the case that
(ATOM X), (CONSP X), and (AND (PATOM X) (NOT (ATOM X))) define
three disjoint classes.
Funargs and SPDL Pointers
←←←←←←←←←←←←←←←←←←←←←←←←←
For those of you who use funargs, it should be noted that
this mechanism has now been integrated with UCI LISP SPDL
pointers. A funarg binding context pointer can now be used with
the various stack-accessing functions, and stack pointers may be
used for the optional funarg argument to EVAL and APPLY. Note in
particular that a pointer of zero always refers to the top level,
so that
(EVAL @<expr> 0)
may always be used to evaluate <expr> using the top-level values
of all variables.
Functions for Controlling Evaluation
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
(CATCH <expr> {<label>})
(CATCH <expr> {(<l1> <e11> . . .)} {(<l2> <e21> . . .)} . . .)
(THROW @<value> {<label>})
CATCH and THROW provide a more convenient method of
programming transfers to a higher level in the control
hierarchy than ERRSET/ERR, which (as the names imply)
were originally designed for error handling rather than
planned (programmed) transfers. CATCH simply evaluates
RUTGERS/UCI LISP MANUAL Page 11
<expr>, and if no THROWs are executed during that
evaluation, returns the value of <expr>. If a THROW is
evaluated and the CATCH has no <label> then the CATCH is
immediately exited with <value> as its value (regardless
of whether the THROW had a <label> or not). An unlabeled
CATCH will thus catch a value thrown by any THROW. If
the CATCH has a <label>, it will catch values thrown only
by a THROW with the same label; other THROWs are passed
on in search of a higher-level CATCH with a matching
label. Finally, a single CATCH can catch a variety of
different THROWs via a SELECTQ-like mechanism as shown
above. Each <l> is either a <label> or a list of
<label>s; if a THROW <lable> matches an <l> or a member
of an <l>, the corresponding <e>s are evaluated and the
value of the last one is returned as the value of the
CATCH. If no labels match, the THROW is passed on in
search of a higher level CATCH. Note that a missing
THROW <label> is equivalent to a <label> of NIL, and may
be caught as such. CATCH and THROW are compiled in-line.
(RPTQ @<n> <expr>)
RPTQ evaluates <expr> <n> times, returning the value of
the <n>th evaluation. If <n> is less than one, no
evaluation is done and NIL is returned. Note that the
special variable RPTN is initialized to one, and is
incremented after each evaluation; it may be referenced
within <expr> if desired. For example, the following
prints the squares of the integers from 1 to 20:
(RPTQ 20. (PRINT (*TIMES RPTN RPTN)))
RPTQ is compiled in-line.
(*APPLY @<fn> @<arglist>)
*APPLY has the same relation to APPLY as *EVAL has to
EVAL, i.e., it is a SUBR instead of an LSUBR, and it does
not take the optional funarg argument. APPLYs without
the funarg argument are compiled as *APPLYs.
(DO <e1> {<e2>} . . .)
DO is equivalent to PROGN.
RUTGERS/UCI LISP MANUAL Page 10
Functions for Manipulating Property Lists
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
(DEFLIST <l> {<defval>} <prop>)
DEFLIST is useful for placing a property on a number of
atomic symbols. <l> should be a list of items, each of
which is either an atomic symbol <a> or a two-element
list (<a> <val>). Each <a> will have a <prop> property
placed on its property list, with a value of <val> if
present, or <defval> if only the atomic symbol was given.
<defval> is optional, with a default value of T assumed.
As an example of the use of DEFLIST, the following will
give TOM and BOB ages of 15, and SAM an age of 20 (i.e.,
the 20 overrides the default value of 15):
(DEFLIST (TOM BOB (SAM 20)) 15 AGE)
(DEFV <atom> <value>)
Equivalent to (SETQ <atom> @<value>), except that <value>
is not evaluated and the value returned is <atom> instead
of <value>. DEFV is used by the prettyprinter to print
VALUE properties.
(DEFP <at1> <at2> <prop>)
Places the <prop> property of <at2> onto <at1>. For
example,
(DEFP DO PROGN FSUBR)
defines DO to be the same function as PROGN.
(ADDPROP @<atom> @<value> @<prop>)
ADDPROP is used to collect a number of values under a
single property. If <atom> has no <prop> property,
(LIST @<value>) is placed onto the property list of
<atom>. If <value> is already a MEMBer of the <prop>
property of <atom> (which is assumed to be a list), no
action is taken. Otherwise <value> is CONSed onto the
front of the list and it is placed back on the property
list of <atom>. The (modified) list is returned as the
value of ADDPROP.
(PUTLIST @<l> @<value> @<prop>)
Places <value> as the <prop> property of each element of
<l> (which should be a list of atomic symbols). PUTLIST
returns NIL.
RUTGERS/UCI LISP MANUAL Page 11
(REMLIST @<l> @<prop>)
Removes the <prop> property from each element of <l>
(which should be a list of atomic symbols). REMLIST
returns NIL.
(REMPROPS @<atom> @<l>)
Treats each element of <l> (a list of atomic symbols) as
a property, removing that property from <atom>. REMPROPS
returns NIL.
(PUT @<atom> @<value> @<prop>)
PUT is equivalent to PUTPROP.
New Mapping Functions
←←←←←←←←←←←←←←←←←←←←←
(MAPATOMS @<fn>)
Applies <fn> (a function of one argument) to every atomic
symbol on the OBLIST and returns NIL. MAPATOMS is
compiled in-line.
(EVERY @<fn> @<l>)
Returns T if <fn> (a function of one argument) is non-NIL
for each element of the list <l>. In other words, <fn>
←←←←
is applied to each element of <l> in turn until either
<fn> returns NIL (in which case EVERY returns NIL), or
<l> is exhausted (with EVERY returning T). For example,
the following checks whether L is a list of atoms:
(EVERY @ATOM L)
EVERY is compiled in-line.
(SOME @<fn> @<l>)
Returns a non-NIL value if <fn> (a function of one
argument) is non-NIL for some element of the list <l>.
←←←←
The value returned is the tail of <l> starting with that
element. SOME is compiled in-line.
(NOTEVERY @<fn> @<l>)
Equivalent to (NOT (EVERY @<fn> @<l>)).
(NOTANY @<fn> @<l>)
Equivalent to (NOT (SOME @<fn> @<l>)).
RUTGERS/UCI LISP MANUAL Page 12
(SUBSET @<fn> @<l>)
Applies <fn> (a function of one argument) to each element
of the list <l>, returning a list consisting of each
element of <l> which causes <fn> to return a non-NIL
value. For example, the following finds all atoms in L:
(SUBSET @ATOM L)
SUBSET is compiled in-line.
New List-Manipulation Functions
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
(UNION @<l1> @<l2>)
Returns a list which is the union of the two lists <l1>
and <l2>. If <l1> and <l2> are of unequal length, UNION
is more efficient if <l2> is the longer list. Note that
membership tests are made using MEMBER (and hence EQUAL).
If MEMB (EQ) checks are desired instead, change the value
of MEMBFN from MEMBER to MEMB.
(INTERSECTION @<l1> @<l2>)
Returns a list which is the intersection of <l1> and
<l2>. See comments for UNION concerning efficiency and
MEMBFN.
(ENTER @<value> @<list>)
Returns <list> if <value> is already a MEMBER of <list>,
otherwise returns <list> with <value> CONSed onto the
front.
(*NCONC @<l1> @<l2>)
*NCONC has the same relation to NCONC as *APPEND has to
APPEND, i.e., it is a SUBR instead of an LSUBR. NCONCs
are compiled as a series of *NCONCs.
(NCONC1 @<list> @<value>)
Adds <value> to the end of <list>. Equivalent to
(NCONC @<list> (LIST @<value>))
RUTGERS/UCI LISP MANUAL Page 13
New Functions on Strings
←←←←←←←←←←←←←←←←←←←←←←←←
(EQSTR @<at1> @<at2>)
Compares the PNAMEs of <at1> and <at2>, returning T if
they are identical and NIL if they differ. Useful for
use with any uninterned atomic symbols (including, of
course, strings).
(SUBSTRING @<str> @<m> @<n>)
Returns a new string consisting of characters <m> through
<n> of <str>. <m> and <n> may be positive integers
(count from left) or negative integers (count from
right). If <m> is non-numeric a value of 1 (first
character) is assumed, and if <n> is non-numeric -1 (last
character) is assumed. Although <str> will typically be
a string, SUBSTRING will actually work with any argument;
←←←
the indicated characters are simply extracted from the
PRINC character string of <str> and formed into a string.
RUTGERS/UCI LISP MANUAL Page 14
IV. NEW I/O FACILITIES
←←←←←←←←←←←←←←←←←←←←←←
The Octal Point "Q"
←←←←←←←←←←←←←←←←←←←
In order to correct the long-standing LISP 1.6/UCI LISP
problem of reading a file which contains numbers which were
printed using a different BASE than the current IBASE, an "octal
point" Q is now printed following numbers when BASE=10. Like the
decimal point (.), the octal point may be turned off by setting
*NOPOINT to T. To summarize the numeric I/O conventions: on
input, any number followed by a Q will be interpreted as octal,
any number followed by a "." will be interpreted as decimal, and
all other integers are interpreted according to the current
setting of IBASE; on output, integers will be printed according
to the current value of BASE, with a Q (BASE=10) or "." (BASE=10)
appended unless *NOPOINT=T. In order to allow the user to
disable the printing of octal or decimal points when interacting
from the terminal but still have points printed when dumping to a
file (so it will be read in correctly), DSKOUT maintains its own
copy of *NOPOINT, called *NOPOINTDSK. Both *NOPOINT and
*NOPOINTDSK are initially NIL (i.e., print points), but either or
both may be changed to T if desired.
36-Bit Integers
←←←←←←←←←←←←←←←
Integers may now be input and output as either signed 35-bit
or unsigned 36-bit numbers. On input, the last 36 bits are
retained (there is no overflow). For example, -1Q and
777777777777Q input as the same quantity. On output, the
decision to print as 36 bits or sign plus 35 bits is under the
control of the variable BASE. If BASE is positive, negative
integers will be printed in standard form (i.e., with a sign).
If BASE is negative, integers will be printed as positive 36-bit
quantities.
Changes to DSKIN/DSKOUT
←←←←←←←←←←←←←←←←←←←←←←←
If the value of the symbol DSKIN is T (its default value)
then DSKIN prints the value of each expression loaded, attempting
to place as many atoms as possible on each line. If the value of
DSKIN is PRINT, the values are printed one per line. If DSKIN is
set to NIL, no printing is done.
FILBAK (the file extension used by DSKOUT to back up a file)
has been changed from LBK to QSP to maintain compatability with
the SOS convention of starting backup files with Q (lets one do
things like .DEL *.Q??).
RUTGERS/UCI LISP MANUAL Page 15
New File-Accessing Functions
←←←←←←←←←←←←←←←←←←←←←←←←←←←←
(GETDEF {<device/directory>} <file> <at1> {<at2>} . . .)
GETDEF is similar to DSKIN, but only one file is accessed
and only selected expressions from that file are read.
In particular, all definitions of each <at> are loaded,
including expressions starting with DEFPROP, DE, DF, DM,
LAP, DEFP, and DEFV (the list of expression types to be
examined is stored as the value of the atom GETDEF, and
may be changed if desired). As usual, <device/directory>
may be omitted, with DSK: assumed. As an example of the
use of GETDEF,
(GETDEF (FUNCS.LSP) FN1 FN2 FN3)
loads any definitions for FN1, FN2, and FN3 found in the
file FUNCS.LSP. The value of each expression loaded is
printed on the terminal for feedback purposes.
(DIRF {<directory>} {<filespec>})
Unlike the function DIR, which returns a list of all the
files in a given directory, DIRF prints the name of each
file in the directory which "matches" <filespec> (it is
thus quite similar in operation to the DIRECT monitor
command). <filespec> may be a dotted pair
(<file>.<ext>), where either <file> and/or <ext> may be *
(match anything), or simply <file>, with (<file>.*)
assumed. Either <directory> or <filespec> or both may be
missing, with the default directory and (*.*) assumed.
(TYPE {<device/directory>} <file1> {<file2>} . . .)
This function types each <file> on the currently selected
output device. Its principle use is to type a text file
on the terminal without leaving LISP, for example,
(TYPE LSP: (ILISP.MAN))
As usual, <device/directory> may be omitted, with DSK:
assumed. Note that if more than one <file> is given they
are simply concatenated together. Thus TYPE could be
used to create a new file which is the concatenation of
FILE1 and FILE2 by doing the following:
(PROGN (OUTC (OUTPUT T NEWFILE))
(TYPE FILE1 FILE2)
(OUTC NIL))
RUTGERS/UCI LISP MANUAL Page 16
New Printing Functions
←←←←←←←←←←←←←←←←←←←←←←
(MSG <i1> {<i2>} . . .)
MSG provides a general message-printing facility for
ILISP. Each <i> is an instruction which provides a
specific formatting capability:
"<string>" Print <string> using PRINAC
<number> Space <number> spaces
(T @<n>) Tab to position <n>
T Move to new line
(E <expr>) Evaluate <expr>
other Eval and print using PRINA
As an example of the use of MSG, consider the following:
(MSG T "Value of X is:" 5 X T)
which is equivalent to:
(PROGN (TERPRI)
(PRINAC @"Value of X is:")
(SPACES 5)
(PRINA X)
(TERPRI))
Note that MSG prints the desired message on the currently
selected output device. MSG is compiled in-line.
(TTYMSG <i1> {<i2>} . . .)
TTYMSG is identical to MSG, except printed output is
directed to the terminal instead of the currently
selected output device. To insure that the message will
appear on the terminal even if ↑O has been struck, a TALK
is performed before printing. TTYMSG is compiled
in-line.
(PRINA @<x> {@<pos>})
Like PRIN1, except if an atom won't fit on the line, a
tab to position <pos> on the next line is performed
before printing resumes. <pos> is optional, with a value
of 1 assumed if omitted.
(PRINAC @<x> {@<pos>})
Identical to PRINA, except PRINC is used to print atoms
instead of PRIN1.
RUTGERS/UCI LISP MANUAL Page 17
(SPACES @<n>)
Spaces over <n> spaces, using tab characters when
possible. If <n> spaces won't fit on the current line,
SPACES performs a TERPRI instead.
(PRINL @<l>)
Prints the list <l> without the outermost parentheses,
i.e., prints the elements of <l> separated by spaces.
Each element is printed using PRINA, with a <pos> of 1.
(PRINLC @<l>)
Identical to PRINL, except uses PRINAC instead of PRINA
to print the list elements.
(PRINTC @<x>)
Identical to PRINT, except uses PRINC instead of PRIN1.
(DPRINT @<x>)
Prints <x> with BASE set to 10 (decimal).
Miscellaneous I/O Functions
←←←←←←←←←←←←←←←←←←←←←←←←←←←
(TALK)
Undoes the effect of a previous ↑O. May be used to
insure that a message will appear on the terminal (see
TTYMSG).
(PEEKC)
Returns the ASCII code of the next character in the input
stream without reading the character. Equivalent to
(UNTYI (TYI)).
(DELIM @<char>)
Returns T if the character whose ASCII code is <char> is
a delimiter (i.e., will stop the formation of an atomic
symbol), and NIL if it isn't. For example,
(DELIM (PEEKC)) checks if the next character in the input
stream will be a delimiter.
(INCH)
Returns the name of the currently selected input channel.
RUTGERS/UCI LISP MANUAL Page 110
(OUTCH)
Returns the name of the currently selected output
channel.
(CURRCOL)
Returns the number of the next available print position.
RUTGERS/UCI LISP MANUAL Page 111
V. NEW DEBUGGING FACILITIES
←←←←←←←←←←←←←←←←←←←←←←←←←←←
Additions to the Editor
←←←←←←←←←←←←←←←←←←←←←←←
(EDIT @<expr>)
If <expr> is an atom EDIT simply returns <expr>;
otherwise the editor is called with <expr> as the object
to be edited.
PP* Command
Prettyprints the current edit expression with COMMENTFLG
set to T.
F, BF Commands
The F and BF commands now save their arguments from one
call to the next; if used without an argument the
previous F or BF pattern is used.
FP, BFP Commands
FP and BFP are equivalent to F and BF followed by a P
(Print). They also save their find patterns from one
call to the next.
Additions to the Break Package
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
(TRACEV <var1> {<var2>} . . .)
TRACEV provides a value-tracing facility for uncompiled
ILISP code. Each time one of the <var>s has its value
changed via SET or SETQ a message showing the new value
is printed. Note that initial variable bindings in
LAMBDA expressions and PROGs, and variables bound within
compiled functions, will not be traced.
(UNTRACEV {<var1>} {<var2>} . . .)
Each variable <var> will have its value tracing turned
off. Like UNBREAK and UNTRACE, (UNTRACEV T) may be used
to untrace the most recently-traced variable, and
(UNTRACEV) turns off all value tracing.
RUTGERS/UCI LISP MANUAL Page 20
VI. THE LISP PRETTYPRINTER
←←←←←←←←←←←←←←←←←←←←←←←←←←
The ILISP prettyprint package provides a powerful facility
for printing functions in readable form and creating formatted
symbolic files. New capabilities include a "printmacro"
mechanism, three levels of user commenting, and a "prettyprint
command" facility for controlling the printing process.
Basic Functions
←←←←←←←←←←←←←←←
(PP <a1> {<a2>} . . .)
(PP replaces the old GRINDEF). If <a> is atomic, each
property of <a> which appears on the list PRETTYPROPS is
printed in readable format. Each non-atomic <a> is
simply printed via SPRINT unless its CAR is defined as a
"prettyprint command", in which case the expression is
evaluated (prettyprint commands are explained further
below). <a> may also be a list consisting of a LAP
expression followed by a sequence of LAP code; such a
list will be printed in standard LAP format.
(PPL <var1> {<var2>} . . .)
(PPL replaces the old GRINL). Each <var> should be an
atomic symbol which is bound to a prettyprint list to be
passed on to PP. This prettyprint list may contain
atomic symbols whose properties are to be printed,
prettyprint command expressions, and other expressions
which are to be SPRINTed. Each <var> (except ALLFNS)
which is not already a member of its prettyprint list
will be printed so that if dumping to a file its value
will be restored when the file is subsequently loaded.
The prettyprint list will disappear when the file is
compiled, however (i.e., it will not appear in the LAP
file).
(SPRINT @<expr> @<col>)
SPRINT is the workhorse of the prettyprint package - it
is used by PP and PPL to print <expr>s in pretty form
starting in column <col>. The prettyprinting
capabilities of SPRINT may be suppressed by setting the
special variable PRETTYFLG to NIL. In this mode, the
prettyprint package may be used to produce fast, compact
(though not very readable) symbolic dumps.
PRETTYPROPS
←←←←←←←←←←←
(PRETTYPROPS replaces the old GRINPROPS). In its simplest
form, PRETTYPROPS is a list of atomic symbols which gives the
properties which PP is to print. Each atomic argument to PP
RUTGERS/UCI LISP MANUAL Page 21
which has a property on PRETTYPROPS will be printed as a DEFPROP
expression. Occasionally, however, it is desirable to print
certain properties in something other than DEFPROP format. This
may be accomplished by putting a consed pair of the form
(<prop> . <fn>) onto PRETTYPROPS; when an atom with a <prop>
property is encountered, PP simply prints a carriage return and
calls <fn>. <fn> will be passed three arguments: the atom
currently being PPed, the value stored under the property <prop>,
and the atom <prop> itself. The function can then print anything
it wishes before returning to PP, at which time another carriage
return will be printed. For example, the functions PP-VALUE and
PP-RMACS are provided by the prettyprint package to print VALUE
and READMACRO properties in special form.
PRETTYPROPS is initialized to (SPECIAL EXPR FEXPR MACRO
(VALUE . PP-VALUE) PRINTMACRO (READMACRO . PP-RMACS)).
Prettyprint Commands
←←←←←←←←←←←←←←←←←←←←
Prettyprint commands may be used as arguments to PP or in
PPL prettyprint lists to perform a variety of special formatting
tasks. A prettyprint command is simply an expression whose CAR
is a function name with a non-NIL PPCOM property. Such
expressions are evaluated when encountered by PP, thus providing
a mechanism for "grabbing control" during the prettyprint
process. The user may define his own prettyprint commands, or
may use the following functions supplied by the system. Note
that in addition to appearing as prettyprint commands in PPL
lists, these expressions may be used in other contexts as well.
(*PG*)
Outputs a page eject; may be used to place various
sections of a large symbolic file on different pages.
(F: <fn1> {<fn2>} . . .)
Prettyprints any functional attributes of each <fn>,
ignoring all other properties. Actually, F: simply sets
PRETTYPROPS to (EXPR FEXPR MACRO) and passes its
arguments on to PP, so each <fn> may be anything which
can normally be used as an argument to PP. PRETTYPROPS
is restored after printing is completed.
(P: <props> <x1> {<x2>} . . .)
PRETTYPROPS is set to <props>, the <x>s are passed on to
PP, and PRETTYPROPS is restored. For example, F: could
be defined as
(P: (EXPR FEXPR MACRO) <fn1> <fn2> . . .)
RUTGERS/UCI LISP MANUAL Page 22
(V: <x1> {<x2>} . . .)
Useful for printing values. Each <x> may be either an
atomic symbol <var> or a list of the form (<var> <val>).
Each <var> will be printed as a DEFV expression, with a
value of <val> if given, or the current value of the
variable if only the variable name was given (unbound
variables are printed with a value of NIL).
(MBD: <fn> <x1> {<x2>} . . .)
Passes the <x>s on to PP in such a way that they will be
prettyprinted inside of an expression starting with <fn>.
For example, to prettyprint F1 and F2 inside of a PROGN
expression (perhaps so they will not be compiled) one
could do:
(MBD: PROGN F1 F2)
(FORMS: <x1> {<x2>} . . .)
Each <x> is passed directly to SPRINT - may be used to
print atoms and prettyprint command expressions which
would normally be handled specially by PP.
(E: <e1> {<e2>} . . .)
The <e>s are simply evaluated. For example, the
inclusion of the following in a prettyprint list could be
used to change the base in the middle of a print:
(E: (SETQ BASE 10.))
Printmacros
←←←←←←←←←←←
SPRINT normally operates by formatting the expression being
printed using indentation to produce "pretty" output. It is
occasionally desirable to have certain subexpressions printed in
some special format for increased readability. Such a capability
is provided via the use of printmacros. Any function may be
←←←←←←←←←←←
flagged as a printmacro by placing the macro definition on the
property list of the atom under the indicator PRINTMACRO.
Whenever an atom with such a property appears as the first
element in a list being prettyprinted, SPRINT takes special
action, such action depending on the value of the PRINTMACRO
property:
(1) If the value is a string the string is simply PRINCed and the
CADR of the original expression (if present) is SPRINTed.
This serves as an inverse for READMACROs of the @<e> ->
(QUOTE <e>) type. For example,
(DEFPROP QUOTE "@" PRINTMACRO)
(DEFPROP THV "$?" PRINTMACRO)
RUTGERS/UCI LISP MANUAL Page 23
(the QUOTE printmacro is in fact already present in ILISP).
(2) If the value is the special atomic symbol BRACKETS then the
expression is printed by SPRINT in the normal way, except
that each top-level non-atomic argument will be printed with
brackets [...] instead of the usual parentheses (...). This
gives the user one more method of producing more readable
output. COND, SELECTQ, AND, OR, and CATCH are initialized as
printmacros of this type. To disable the use of brackets for
these functions simply REMPROP the PRINTMACRO property from
their property lists.
(3) If the value of the PRINTMACRO property is neither a string
nor the atomic symbol BRACKETS it is assumed to be a true
printmacro function (or, more typically, the name of a
function). This function will be passed the expression being
printed as its only argument, and may print it in any format
it wishes. For example, in lieu of defining QUOTE as a
string printmacro, one could do the following:
(DEFPROP QUOTE
(LAMBDA (E) (PRINC @"@") (SPRINT (CADR E) (CURRCOL)))
PRINTMACRO)
To make the writing of printmacro functions easier several
auxilliary formatting functions are provided:
(PP-FORMAT @<e> @<n> @<flag>)
Prints the expression <e> with the first <n>+1 elements
(the function name and <n> arguments) printed on one
line. <flag> specifies how the remaining arguments are
to be printed: if <flag>=NIL (standard format), all
remaining arguments are printed under the first argument;
if <flag>=MISER, the remaining arguments are placed under
the function name; if <flag>=LABELS, all non-atomic
arguments are printed under the first argument, with
atoms placed to the left as labels.
(PP-MISER @<e>)
Equivalent to:
(PP-FORMAT @<e> 1 @MISER)
This is the system printmacro function used for LAMBDA
and DEFPROP.
(PP-LABELS @<e>)
Equivalent to:
(PP-FORMAT @<e> 1 @LABELS)
This is the system printmacro function used for PROG.
RUTGERS/UCI LISP MANUAL Page 24
Comments
←←←←←←←←
One of the major disadvantages of many LISP systems is the
lack of a usable commenting facility. This has been remedied in
ILISP by the addition of three levels of comments: *, **, and
***. These atoms are defined as macros which expand to NIL;
expressions starting with *, **, or *** may be placed in function
definitions anywhere a NIL could be placed without harm, e.g., at
the top level of LAMBDAs and PROGs (when the function is
subsequently compiled, these expressions will disappear). *, **,
and *** are also defined as printmacros which cause the
expression to be printed in block form as a comment. * comments
are intended to be used for detailed descriptions of code - they
are printed starting in column 40. ** comments are intended to
serve as top-level descriptions of functions - they are printed
starting in column 10. *** comments are intended to be used in
prettyprint lists to describe major sections of a symbolic file
(perhaps following a (*PG*) prettyprint command) - they are
printed starting in column 1.
Comment atoms are flagged by placing the function name
PP-COMMENT on the property list of the atom under the PRINTMACRO
property, and putting the desired starting print column on the
property list under the property COMMENT. The user may thus
disable *, **, and/or *** as comment atoms by removing these two
properties, or may change the starting column or add new comment
atoms if desired.
Note that comments are intended primarily to comment
symbolic files - when printing to the terminal all comments
appear simply as *COMMENT* unless the special variable COMMENTFLG
is non-NIL. The functions PP* and PPL*, and the edit command
PP*, may be used to print function definitions with comments on
the terminal (i.e., they first set COMMENTFLG to T).
Note also that comments are treated by LISP as normal list
structures, and hence must obey all LISP syntax rules. In
particular, this means that periods may not be used and commas
will disappear. It is suggested that ";" be used instead of
period as a terminator as it is not a LISP punctuation mark and
thus simply becomes part of an atomic symbol.
RUTGERS/UCI LISP MANUAL Page 25
VII. THE COMPILER AND LAP
←←←←←←←←←←←←←←←←←←←←←←←←←
The ILISP compiler (ILISPC) is an extended (and debugged)
version of the Stanford LISP 1.6 compiler. As before, a file of
LISP functions is compiled via the function COMPL, which takes a
file specification (like DSKIN) and creates a LAP file which can
subsequently be loaded via DSKIN.
Declarations
←←←←←←←←←←←←
Although the use of the compiler is quite straightforward,
there are several declarations which can (and sometimes must) be
made to give the compiler additional information about your code.
These declarations should appear at the beginning of the file
inside a DECLARE expression:
(DECLARE <d1> {<d2>} . . .)
Each <d> is a compiler declaration expression - such
declarations are ignored when the file containing the
DECLARE is loaded, but are evaluated when the file is
compiled. Available declarations are given below.
(SPECIAL <var1> {<var2>} . . .)
Declares each <var> as a special variable, i.e., a
variable which appears free in a function. Note that
free variables in in-line LAMBDA expressions and LAMBDA
expressions used as arguments to most system functions
(e.g., the MAP functions) need not be declared SPECIAL,
as such functions are compiled in-line. In addition
ERRSETs are now compiled in-line, so variables in ERRSET
expressions no longer have to be declared SPECIAL. All
undeclared free variables in a file may be found by
compiling the file and examining the error messages; for
convenience, the compiler places all newly-discovered
special variables on the list SPECIALS.
(UNSPECIAL <var1> {<var2>} . . .)
This declaration may be used to inform the compiler that
certain variables are no longer considered special, and
should be compiled as normal local variables in
subsequent functions.
(NOCALL <a1> {<a2>} . . .)
Each <a> should be either the name of a function to be
compiled or a special variable. These functions and
variables are assumed to be local to the file being
compiled and will thus never be traced, called or
referenced from functions not in this file, or used as
entry points or top-level values. The compiler can
RUTGERS/UCI LISP MANUAL Page 26
compile references to such functions as direct jumps, and
the atoms may be REMOBed when the file is loaded (see
DUMPATOMS below). It is also possible to cause all
←←←
function references to be changed to direct jumps when a
LAP file is loaded (see below).
(CALL <fn1> {<fn2>} . . .)
Specifies that each <fn> should always be called via the
←←←←←←
function-calling mechanism and not changed to direct
jumps. Necessary in rare cases when the new NOCALL=T
feature is being used (see below for further
explanation).
(GLOBALMACRO <mac1> {<mac2>} . . .)
Macro definitions are normally assumed to be used only by
functions in the file in which they appear, and hence are
not necessary after the file is compiled. Occassionally,
however, it is desirable to keep the macro definitions
after compilation by having them copied into the LAP file
(PLUS is such a macro for example). The GLOBALMACRO
declaration specifies that each <mac> is such a global
macro and should be saved.
(*SUBR/*FSUBR/*LSUBR <fn1> {<fn2>} . . .)
FSUBRs and LSUBRs which are referenced before they are
compiled must be declared (via *FSUBR and *LSUBR) so that
the compiler can compile function references correctly.
*SUBR declarations may also be made, although they are
not necessary since all undefined functions are assumed
to be SUBRs. *EXPR, *FEXPR, and *LEXPR may be used in
place of *SUBR, *FSUBR, and *LSUBR if desired.
Extensions to NOCALL
←←←←←←←←←←←←←←←←←←←←
As stated above, NOCALL declarations are intended to flag
atomic symbols (both functions and, in the Rutgers ILISP system,
special variables) which are not necessary after a LAP file is
loaded and may thus be REMOBed (only the special cell of a
variable is actually referenced by compiled code). In order to
make this process reversible, the following function is now
provided:
(DUMPATOMS {<file>})
After loading a set of files which contain NOCALL
declarations, DUMPATOMS may be called to REMOB all NOCALL
atoms after first creating a file <file> which, when
subsequently loaded, will restore the SUBR, FSUBR, LSUBR,
VALUE, and SYM properties of each NOCALL atom. One can
thus use DUMPATOMS to REMOB all NOCALL atoms (to save
space), and if it is later discovered that one of the
RUTGERS/UCI LISP MANUAL Page 27
functions or special variables is needed after all, DSKIN
the DUMPATOMS file to restore things to their previous
state. If <file> is missing, (REMOB.LSP) is assumed.
In addition to saving space by allowing unnecessary atomic
symbols to be REMOBed, NOCALL declarations provide for faster
execution by replacing function calls with direct jumps. It is
now possible to cause all function calls to be loaded as direct
←←←
jumps by setting NOCALL to T before loading the relevant files
(it should be set back to NIL after loading is completed). Note
that this should be done only after all functions are completely
debugged, as none of the functions can be traced or redefined
after loading. Specific functions may be exempted from this
inclusive NOCALL by declaring them CALL at compile time (see
above). This is optional in some cases (e.g., one wants to be
able to trace a particular function), and necessary in others.
In particular, any function which is listed as "undefined" at
compile time must be declared CALL unless a compiled version of
the function will later be loaded along with the LAP file.
Note that when loading LAP files with NOCALL=T all functions
are assumed to be either already defined when the files are
loaded (e.g., system functions), or defined in the file. If any
existing compiled functions (such as system functions) are to be
redefined, they must either be defined before they are referenced
or must have their SUBR, FSUBR, or LSUBR properties removed
before loading. A warning will be printed if this is not done.
In-Line Code
←←←←←←←←←←←←
A number of system functions are compiled in-line by the
compiler, either because they generate only a few words of code
or because they are FEXPRs which evaluate one or more arguments
(if calls to such functions were not compiled in-line, the
uncompiled arguments would be passed to the interpreter, slowing
down execution considerably). Functions currently compiled
in-line include:
ERRSET, CATCH, THROW, RPTQ, COND, AND, OR, SELECTQ,
PROG1, PROG2, PROGN (and DO), PROG, RETURN, GO, SETQ,
MSG, TTYMSG, SUBSET, EVERY, SOME, NOTANY, NOTEVERY, All
Map Functions, APPEND (as *APPENDs), NCONC (as *NCONCs),
LIST (as CONSes), CAR, CDR, RPLACA, RPLACD, EQ, NEQ, NULL
(and NOT), ZEROP, ARG, SETARG, STORE, EVAL (as *EVAL or a
direct call if possible), APPLY (as *APPLY or a direct
call if possible), and APPLY# (as a direct call if
possible).
RUTGERS/UCI LISP MANUAL Page 210
Other Extensions
←←←←←←←←←←←←←←←←
The compiler normally works by compiling all function
definitions in the file (putting the compiled code in the LAP
file), and copying all other expressions into the LAP file
unchanged (except for comments and DECLARE expressions). It is
sometimes desirable to change this standard convention. For
example, the GLOBALMACRO declaration causes macros to be used by
the compiler and also copied to the LAP file. Certain functions
may have their compilation suppressed (with the symbolic
definition copied to the LAP file) by placing their definitions
inside a PROGN (the MBD: prettyprint command is useful for
this). A new capability is now available which allows certain
expressions to be evaluated when the symbolic file is loaded, but
to not be copied to the LAP file. This is accomplished by
placing the expressions inside a NOCOMPILE (which acts like a
PROGN when evaluated). For example, the prettyprint package
causes PPL prettyprint lists to disappear at compile time by
placing the variable binding inside a NOCOMPILE expression.
Recall that strings are normally not interned by the READ
routine so that they will be garbage collected when no longer
referenced. Strings appearing in compiled code will always be
referenced, however, so LAP has been modified to intern them.
This has the advantage that functions which are compiled may
reference the same string a number of times without penalty -
only one copy will be stored.
The compiler now prints the name of each function before its
compilation has begun. If an error occurs, the last name printed
is the function in error. Note also that the value returned by
LAP (and thus printed by DSKIN) is now a list consisting of the
name of the function loaded followed by the number of words of
binary program space required for the compiled code.
RUTGERS/UCI LISP MANUAL Page 211
VIII. INFORMATION FOR THE SYSTEM BUILDER
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
User Error Handling
←←←←←←←←←←←←←←←←←←←
Recall that errors currently cause a message to be printed
and a break to the break package to occur (unless an ERRSET is
suppressing error messages or the break package has been turned
off via (*RSET NIL)). The user now has the capability to grab
control whenever an error is encountered by setting USERERRORX to
the name of an error-handling function. If the user error
handler returns NIL the system break package is entered, giving
the user the ability to examine the form which caused the error
(it is on the stack) and conditionally break to the break
package. Otherwise it is assumed that the user error handler
will process the error and either return a non-NIL value to
continue the computation or restart at some other point. Note
that the user error function should be a function of one
argument, which in most cases should be ignored (it is an
indication as to whether ILISP considers the error a "serious"
error (T) or a "correctable" error (NIL); error messages for
correctable errors may be suppressed via (*RSET @ERRORX)).
Creating One's Own System
←←←←←←←←←←←←←←←←←←←←←←←←←
Most users who create their own ILISP-based system will want
to save only the low segment of their core image, with ILISP's
sharable high segment loaded at run time. This may be
accomplished by exiting from ILISP via (EXIT NIL), which removes
the high segment so that SAVE will create only a SAV (low
segment) file instead of LOW and HGH files. When such a SAV file
is later RUN, ILISP's standard sharable high segment will
automatically be loaded. Note that an EXCISE or a SYSCLR should
always be done before exiting and saving ILISP - if this is not
done the I/O buffers will be allocated as available space,
causing the ALLOC? message to appear each time the saved program
is run.
Although it is suggested that most ILISP-based systems share
the standard ILISP high segment as outlined above (ILISPC, FUZZY,
etc. are of this type), it may be desirable that a heavily-used
system with large amounts of compiled code have its own sharable
high segment. In order to do this one must have write privileges
for the system (see discussion under SETSYS in the UCI LISP
manual), and must execute a HGHCOR to allocate space for compiled
code in the high segment. The compiled code may then be loaded
via the new function HGHIN, which is identical to DSKIN except
compiled code is placed in the high segment. The following
summarizes the procedure necessary to create a sharable system:
RUTGERS/UCI LISP MANUAL Page 30
.R ILISP
*(SETSYS (<proj>,<prog>) <name of system>)
*(EXIT T)
.SSA <name of system>
.RU <name of system>
*(HGHCOR <# of words of compiled code>)
*(REALLOC <other space allocations> . . .)
*(SETQ NOCALL T)
*(HGHIN <your files>)
*(SETQ NOCALL NIL)
*(SYSCLR)
*(INITFN @<fn to print header>)
*(EXIT T)
.SSA <name of system>
Building ILISP
←←←←←←←←←←←←←←
The files ILISP.BLD, ILISPC.BLD, PLNR.BLD, CNVR.BLD, and
FUZZY.BLD contain detailed instructions (and code) for building
the various ILISP modules. They should be consulted if any of
these systems need to be reconstructed. After constructing the
various modules, the following files should be copied into SYS:
ILISP.LOW
ILISP.SHR
ILISP.LOD
ILISP.SYM
ILISPC.SAV
PLNR.SAV (if desired)
CNVR.SAV (if desired)
FUZZY.SAV (if desired)
RUTGERS/UCI LISP MANUAL Page 31
INDEX
←←←←←
* . . . . . . . . . . . . . . . . . . . . . . . 24
** . . . . . . . . . . . . . . . . . . . . . . . 24
*** . . . . . . . . . . . . . . . . . . . . . . 24
*APPLY . . . . . . . . . . . . . . . . . . . . . 11
*FSUBR (or *FEXPR) . . . . . . . . . . . . . . . 26
*LSUBR (or *LEXPR) . . . . . . . . . . . . . . . 26
*NCONC . . . . . . . . . . . . . . . . . . . . . 12
*NOPOINT . . . . . . . . . . . . . . . . . . . . 14
*NOPOINTDSK . . . . . . . . . . . . . . . . . . 14
*PG* . . . . . . . . . . . . . . . . . . . . . . 21, 24
*SUBR (or *EXPR) . . . . . . . . . . . . . . . . 26
ADDPROP . . . . . . . . . . . . . . . . . . . . 10
ALLFNS . . . . . . . . . . . . . . . . . . . . . 5
ATOM . . . . . . . . . . . . . . . . . . . . . . 10
BASE (With Negative Value) . . . . . . . . . . . 14
BF (Edit Command) . . . . . . . . . . . . . . . 111
BFP (Edit Command) . . . . . . . . . . . . . . . 111
BRACKETS . . . . . . . . . . . . . . . . . . . . 23
CALL . . . . . . . . . . . . . . . . . . . . . . 26-27
CATCH . . . . . . . . . . . . . . . . . . . . . 10-11
COMMENT . . . . . . . . . . . . . . . . . . . . 24
COMMENTFLG . . . . . . . . . . . . . . . . . . . 111, 24
COMPL . . . . . . . . . . . . . . . . . . . . . 25
CONSP . . . . . . . . . . . . . . . . . . . . . 10
CURRCOL . . . . . . . . . . . . . . . . . . . . 110
DATE . . . . . . . . . . . . . . . . . . . . . . 7
DECLARE . . . . . . . . . . . . . . . . . . . . 25
DEFLIST . . . . . . . . . . . . . . . . . . . . 10
DEFP . . . . . . . . . . . . . . . . . . . . . . 10
DEFV . . . . . . . . . . . . . . . . . . . . . . 10
DELIM . . . . . . . . . . . . . . . . . . . . . 17
DIRF . . . . . . . . . . . . . . . . . . . . . . 15
DO . . . . . . . . . . . . . . . . . . . . . . . 11
DPRINT . . . . . . . . . . . . . . . . . . . . . 17
DSKIN (Printing Control) . . . . . . . . . . . . 14
DTIME . . . . . . . . . . . . . . . . . . . . . 7
DUMPATOMS . . . . . . . . . . . . . . . . . . . 26
E: . . . . . . . . . . . . . . . . . . . . . . . 22
EDIT . . . . . . . . . . . . . . . . . . . . . . 111
EDITCH . . . . . . . . . . . . . . . . . . . . . 5
ENTER . . . . . . . . . . . . . . . . . . . . . 12
EQSTR . . . . . . . . . . . . . . . . . . . . . 13
ERRCH . . . . . . . . . . . . . . . . . . . . . 5
ERRSET . . . . . . . . . . . . . . . . . . . . . 25
EVERY . . . . . . . . . . . . . . . . . . . . . 11
EXIT . . . . . . . . . . . . . . . . . . . . . . 4, 6-7
EXPBPS . . . . . . . . . . . . . . . . . . . . . 6
EXPFS . . . . . . . . . . . . . . . . . . . . . 6
EXPFWS . . . . . . . . . . . . . . . . . . . . . 6
F (Edit Command) . . . . . . . . . . . . . . . . 111
F: . . . . . . . . . . . . . . . . . . . . . . . 21
FILBAK . . . . . . . . . . . . . . . . . . . . . 14
FORMS: . . . . . . . . . . . . . . . . . . . . . 22
FP (Edit Command) . . . . . . . . . . . . . . . 111
FSCNT . . . . . . . . . . . . . . . . . . . . . 7
Funarg Pointers . . . . . . . . . . . . . . . . 10
FWCNT . . . . . . . . . . . . . . . . . . . . . 7
GETDEF . . . . . . . . . . . . . . . . . . . . . 15
GLOBALMACRO . . . . . . . . . . . . . . . . . . 26
HGHIN . . . . . . . . . . . . . . . . . . . . . 211
INCH . . . . . . . . . . . . . . . . . . . . . . 17
INTERSECTION . . . . . . . . . . . . . . . . . . 12
MAPATOMS . . . . . . . . . . . . . . . . . . . . 11
MBD: . . . . . . . . . . . . . . . . . . . . . . 22, 210
MEMBFN . . . . . . . . . . . . . . . . . . . . . 12
MSG . . . . . . . . . . . . . . . . . . . . . . 16
NCONC1 . . . . . . . . . . . . . . . . . . . . . 12
NIL (CAR and CDR = NIL) . . . . . . . . . . . . 10
NOCALL . . . . . . . . . . . . . . . . . . . . . 25-27
NOCOMPILE . . . . . . . . . . . . . . . . . . . 210
NOTANY . . . . . . . . . . . . . . . . . . . . . 11
NOTEVERY . . . . . . . . . . . . . . . . . . . . 11
OUTCH . . . . . . . . . . . . . . . . . . . . . 110
P: . . . . . . . . . . . . . . . . . . . . . . . 21
PATOM . . . . . . . . . . . . . . . . . . . . . 10
PEEKC . . . . . . . . . . . . . . . . . . . . . 17
PP . . . . . . . . . . . . . . . . . . . . . . . 20
PP* . . . . . . . . . . . . . . . . . . . . . . 24
PP* (Edit Command) . . . . . . . . . . . . . . . 111, 24
PP-COMMENT . . . . . . . . . . . . . . . . . . . 24
PP-FORMAT . . . . . . . . . . . . . . . . . . . 23
PP-LABELS . . . . . . . . . . . . . . . . . . . 23
PP-MISER . . . . . . . . . . . . . . . . . . . . 23
PPCOM . . . . . . . . . . . . . . . . . . . . . 21
PPL . . . . . . . . . . . . . . . . . . . . . . 20
PPL* . . . . . . . . . . . . . . . . . . . . . . 24
PRETTYPROPS . . . . . . . . . . . . . . . . . . 20
PRINA . . . . . . . . . . . . . . . . . . . . . 16
PRINAC . . . . . . . . . . . . . . . . . . . . . 16
PRINL . . . . . . . . . . . . . . . . . . . . . 17
PRINLC . . . . . . . . . . . . . . . . . . . . . 17
PRINTC . . . . . . . . . . . . . . . . . . . . . 17
PRINTMACRO . . . . . . . . . . . . . . . . . . . 22
PUT . . . . . . . . . . . . . . . . . . . . . . 11
PUTLIST . . . . . . . . . . . . . . . . . . . . 10
Q (The Octal Point) . . . . . . . . . . . . . . 14
REALLOC . . . . . . . . . . . . . . . . . . . . 6
REMLIST . . . . . . . . . . . . . . . . . . . . 11
REMPROPS . . . . . . . . . . . . . . . . . . . . 11
REREADCH . . . . . . . . . . . . . . . . . . . . 5
RPTN . . . . . . . . . . . . . . . . . . . . . . 11
RPTQ . . . . . . . . . . . . . . . . . . . . . . 11
SOME . . . . . . . . . . . . . . . . . . . . . . 11
SPACES . . . . . . . . . . . . . . . . . . . . . 17
SPDL Pointers . . . . . . . . . . . . . . . . . 10
SPECIAL . . . . . . . . . . . . . . . . . . . . 25
SPECIALS. . . . . . . . . . . . . . . . . . . . 25
SPRINT . . . . . . . . . . . . . . . . . . . . . 20
SUBSET . . . . . . . . . . . . . . . . . . . . . 12
SUBSTRING . . . . . . . . . . . . . . . . . . . 13
TALK . . . . . . . . . . . . . . . . . . . . . . 16-17
THROW . . . . . . . . . . . . . . . . . . . . . 10-11
TIMER . . . . . . . . . . . . . . . . . . . . . 7
TRACEV . . . . . . . . . . . . . . . . . . . . . 111
TTYMSG . . . . . . . . . . . . . . . . . . . . . 16
TYPE . . . . . . . . . . . . . . . . . . . . . . 15
UNION . . . . . . . . . . . . . . . . . . . . . 12
UNSAVE . . . . . . . . . . . . . . . . . . . . . 5-6
UNSPECIAL . . . . . . . . . . . . . . . . . . . 25
UNTRACEV . . . . . . . . . . . . . . . . . . . . 111
USERERRORX . . . . . . . . . . . . . . . . . . . 211
V: . . . . . . . . . . . . . . . . . . . . . . . 22
↑C . . . . . . . . . . . . . . . . . . . . . . . 4
↑D . . . . . . . . . . . . . . . . . . . . . . . 4
↑F . . . . . . . . . . . . . . . . . . . . . . . 5
↑G . . . . . . . . . . . . . . . . . . . . . . . 5
↑O . . . . . . . . . . . . . . . . . . . . . . . 16-17
↑X . . . . . . . . . . . . . . . . . . . . . . . 4, 7
↑Z . . . . . . . . . . . . . . . . . . . . . . . 5